Skip to content

Added support for passing client prop to Provider wrapper component#69

Closed
heysailor wants to merge 3 commits into
wix:masterfrom
heysailor:master
Closed

Added support for passing client prop to Provider wrapper component#69
heysailor wants to merge 3 commits into
wix:masterfrom
heysailor:master

Conversation

@heysailor
Copy link
Copy Markdown

@heysailor heysailor commented Jun 19, 2016

Passing a client prop to the allows use of libraries such as Apollo Client, which depend on access to the root element.

More information: http://docs.apollostack.com/apollo-client/react.html

For example, the Apollo Client library has an enhanced ApolloProvider component to allow access to its client in the react tree. It depends on a client prop. This PR allows use as below:

app.js:

/* ...create redux store, etc  */

import ApolloClient from 'apollo-client';
import { ApolloProvider } from 'react-apollo';
import { registerScreens } from './screens'; // react-native-navigation

const client = new ApolloClient();

registerScreens(store, ApolloProvider, client);

registerScreens.js:

/* ... import screens ... */

export function registerScreens(store, Provider, client) {
  Navigation.registerComponent('cz.ScreenWithApolloDependencies', () => ScreenWithApolloDependencies, store, Provider, client);
}

Another viable alternative would a more generic way of passing props to the <Provider /> component. This could be as simple as taking a 4th providerProps argument where I've put 'client', which would then be spread on to <Provider />.

@guyca guyca assigned DanielZlotin and unassigned talkol Jun 23, 2016
@brianjd
Copy link
Copy Markdown
Contributor

brianjd commented Aug 22, 2016

Thanks for adding this @heysailor! When can we expect this to be merged?

@heysailor
Copy link
Copy Markdown
Author

I think we're waiting for some major library structure decisions to be made, from other emails I've received. If you look at the merge changes, it's trivial to implement if you want it in the meantime.

On Tue, Aug 23, 2016 at 5:34 AM +1000, "b_d" notifications@github.com wrote:

Thanks for adding this @heysailor! When can we expect this to be merged?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@smooJitter
Copy link
Copy Markdown

It is easy to customize your own registerComponent( ) function. Another possibility is to use registerComponent and yet pass in a wrapped component. E.g, Navigation.registerScreen('screenId', () => <ApolloProvider ...> screen ). I haven't tried it but essentially, that's the only difference.

@heysailor
Copy link
Copy Markdown
Author

That's true, and I do use a custom screen registration function (so I can centralise settings and a few other things).
But adding a client in the way proposed by this PR means you don't have problems accessing the redux state.

On Tue, Aug 23, 2016 at 9:02 PM +1000, "smooJitter" notifications@github.com wrote:

It is easy to customize your own registerComponent( ) function. Another possibility is to use registerComponent and yet pass in a wrapped component. E.g, Navigation.registerScreen('screenId', () => screen ). I haven't tried it but essentially, that's the only difference.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@DanielZlotin
Copy link
Copy Markdown
Contributor

Should be handled by #233

@guns2410
Copy link
Copy Markdown
Contributor

guns2410 commented Jan 5, 2017

Please merge this...

@jer-sen
Copy link
Copy Markdown
Contributor

jer-sen commented Jun 1, 2017

.. and add this to the online documentation !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants